Machine to Machine (M2M) communication, namely the MTC, refers to communication between two MTC devices or communication between an MTC device and an MTC server. The MTC applies widely in aspects such as transportation (logistic scheduling, positioning and navigation), electricity (remote meter reading and load monitoring), city management (elevator monitoring, street lamp control), and home life (elderly care, home security), and may be implemented via a network of an operator.
FIG. 1 is a schematic diagram of MTC architecture in related art, where an Evolved Packet System (EPS) serves as a bottom layer bearer network. A mobile network functioning network element and an MTC service functioning network element are included in FIG. 1.
A mobile network functioning network element includes: a Mobile Switching Centre (MSC), a Serving General Packet Radio Service Support Node (SGSN), a Mobility Management Entity (MME), a Home Subscriber Server (HSS), a Short Message Service-Service Centre (SMS-SC), a Charging Data Function (CDF), a Charging Gateway Function (CGF), etc.
An MTC service functioning network element includes: an MTC InterWorking Function (MTC-IWF) entity, an MTC server, and an MTC device.
An MTC-IWF is an access gateway provided by a mobile network to an MTC, and mainly serves for: implementing InterWorking of an external Internet Protocol (IP) network (where an MTC server is usually located) and the mobile network; authenticating an identifier of an MTC server; authorizing control-plane request signalling sent by an MTC server; and receiving and responding to a series of device trigger request sent by an MTC server.
In an MTC service, a most typical and most important service is a device trigger, in which when there is no application-layer contact (such as service registering contact) between an MTC server and an MTC device and the MTC server is to communicate with the MTC device, the MTC server sends requests a mobile network to convey a device trigger request sent by the MTC server to the MTC device, such that after receiving the device trigger request, the MTC device can take the initiative to establish a communication connection with the MTC server.
In related art, a trigger sent by an MTC server to an MTC device has to go through an MTC-IWF, which delivers the trigger to a core network element. The core network element delivers the trigger to the target MTC device through a proper route. An MTC-IWF may forward the trigger to an MTC device in two ways as follows:
1. the MTC-IWF converts the received trigger into a Short Message (SM) format trigger and delivers the trigger to an SMS-SC through a T4 interface, and the trigger is then forwarded to the MTC device; or
2. the MTC-IWF delivers the trigger to an MME/SGSN/MSC through a T5 interface, and the MME/SGSN/MSC may deliver the trigger to the target MTC device directly through a downlink Network Access Service (NAS) message.
As MTC device trigger is different from a general messaging service such as a Short Message Service (SMS), charging for MTC device trigger differs significantly from general SM charging.
When a trigger is delivered by SMS, with an existing charging method for SMS, the trigger cannot be distinguished from a general short message; a source sending the trigger (which is an MTC service provider usually) cannot be identified explicitly, such that a discriminatory charging strategy cannot be applied.
FIG. 2 is a flowchart of online charging for SMS in related art, where after receiving a short message (SM), while delivering/forwarding the SM, an SMS node generates charging information for the SM and sends the charging information for the SM to an Online Charging Subsystem (OCS).
The SMS node may be an SMS router, an Internet Protocol-Short Message-Gateway (IP-SM-GW) or an SMS-SC.
In the flow as shown in FIG. 2, taking the SMS-SC as an example, a charging flow for SMS may include steps as follows.
In Step 201, an SMS-SC receives an incoming SM-Submit or MAP-Forward-SM.
In Step 202, the SMS-SC sends an OCS a Credit Control Request (CCR) including an SM-Message-Type field indicating an SM type such as an SM to be submitted or an SM to be forwarded.
The CCR may be a debit units request in Immediate Event Charging (IEC), or a Reserve Units Request Initial/Terminate in Event Charging with Unit Reservation (ECUR).
In Step 203, the OCS performs credit control according to the received request.
In Step 204, the OCS returns a Credit Control Response (CCA) to the SMS-SC.
The CCA may be a Debit Units Response in IEC, or a Reserve Units Response Initial/Terminate in ECUR.
In Step 205, the SMS-SC continues to execute an SM forwarding flow.
It can be seen from the flow in FIG. 2 that with an existing charging mechanism for SM, it is only possible to identify an SM to be submitted or an SM to be forwarded, instead of identifying an SM of a particular service For example, in device trigger in an MTC service, when an SM is used to bear a device trigger request, with an existing charging mechanism, a flexible charging requirement for the MTC service cannot be fulfilled, as it cannot tell whether an SM is for a particular service such as device trigger in an MTC service, thereby failing to charge for different service types.
MTC-service development demands more from a mobile network, such as small data transmission, location specific trigger, etc. Such services all demand for discriminatory charging. For example, when control plane signalling is used for bearing a service load, efficient identification of an MTC service type will be key to a charging system.
Further, even for services of the type, charging will differ depending on different SM senders. To meet such requirements, a charging system has to obtain more information.
In view of this, a charging method for an MTC service has to be proposed, such that a charging system can obtain effective information enough for identifying MTC service information, so as to charge with discrimination. However, there is no such solution in related art.